Conventional computer program architecture consists of a main program and a plurality of program modules. The main program typically controls and coordinates the operation of the program modules. FIG. 1 is a schematic diagram of a program 100 having such an architecture. In FIG. 1, a main program 102 contains a plurality of statements, such as 104 and 106. Some of the statements could be CALL statements, such as statements 108 and 110. These two CALL statements, when executed, will invoke program modules 120 and 130. Main program 102 may contain a LOOP statement which causes main program 102 to execute continuously in a loop. Main program 102 also contains a STOP statement for terminating the program. It should be appreciated that program 100 could be written in different programming languages, and the precise syntax of the statements and program structure could vary with the programming languages.
Program 100 contains a plurality of program modules, such as modules 120 and 130, called by main program 102. Module 120 contains a plurality of statements, such as statements 122 and 124. It could also contain a plurality of CALL statements, such as statement 126. This statement, when executed, will invoke another module 140. Finally, module 120 contains a RETURN statement.
When CALL statement 108 is executed, main program 102 jumps to module 120. Statements 122, 124 and the rest of the program are executed. Upon executing the RETURN statement in module 120, program 100 returns to statement 106, which is the statement following CALL statement 108. At this time, the control of program 100 is returned to main program 102. Main program 102 continues to execute.
The structure of all the modules is similar to that of module 120. Similarly, the jump-return mechanism, described above, is carried out by all the CALL statements in program 100. Consequently, they will not be further described in this specification.
In order to carry out this jump-return mechanism, the return addresses of the CALL statements need to be saved in RAM (typically in a memory structure called a stack). Other essential state information of the computer prior to jumping to the called module, such as values of registers, may also be saved if there is a need to do so (e.g., when jumping to an interrupt service routine). Thus, when main program 102 calls module 120, the contents of these registers may also be pushed (i.e., saved) in the stack. Similarly, when module 120 calls module 140, the return address of module 120 also needs to be saved. The contents of appropriate registers may need to be pushed in the stack. Thus, the size of the stack could be large when a large number of CALL statements are executed.
When a RETURN statement is executed, the return address is used to return to the calling program. The saved information is also retrieved.
Typically, a program in the above described conventional architecture contains many CALL statements and many modules. These modules could call other modules (e.g., module 120 can call module 140), thereby forming a chain of CALL statements. The precise history of this chain needs to be preserved so that the last called module can return to the main program. One of the problems of the conventional architecture is that the time to travel the chain could be very long. As pointed out above, each time a CALL statement is invoked, certain amount of state information needs to be saved, resulting in overhead in execution. Each time a RETURN statement is executed, the saved information needs to be restored, again requiring overhead in execution. As a result, the execution speed of programs written using conventional architecture is slow.
The following are some of the characteristics of the conventional architecture: (a) there is a controlling ("boss") program, e.g., main program 102, (b) all the linkage information (e.g., return address and registers) needs to be preserved when one part of the program (a calling program such as main program 102 or some of the modules) transfers execution to another (the called program), and (c) the linkage information is used to return control and information to the calling program. This architecture could be called a "boss" architecture. The calling module can be considered a master while the called module can be considered a slave executing commands issued by the master and then reporting results to the master.
Recently, other programming architectures have been developed. However, they are also based on the boss architecture. One example is object-oriented programming. This method allows codes to be reused and applications developed relatively rapidly. However, the applications still have a controlling body which adds tremendous overhead.
Advances in program architecture have also been made in operating environments. One example is an interprocess communication protocol called dynamic data exchange (DDE) used in Microsoft's MS Windows environment. DDE uses a shared memory to exchange data between processes and a protocol to synchronize the passing of data. The heart of DDE protocol is the DDE message. A process (client) can ask another process (server) to perform a service. Specifically, the client issues a WM_DDE_EXECUTE message to post a command to the server by storing a command string in a global memory block and passing to the server a handle to the global memory block. The server subsequently returns a WM_DDE_ACK message to the client. If the server successfully executes the command, the WM_DDE_ACK message would return a TRUE value to a DDEACK structure member labelled "fAck." If the command is not successfully executed, the server posts a WM_DDE_ACK message with "fAck" set to FALSE. When the client receives the WM_DDE_ACK message from the server, it deletes the command string from global memory and proceeds to take appropriate actions accordingly.
It is clear that interprocess communication via DDE has many characteristics of the conventional architecture shown in FIG. 1. Specifically, the preservation of linkage information and the return of control to the client are important aspects of DDE. While the architecture of FIG. 1 stores the content of a few registers and the return address in each interprocess communication, DDE uses elaborate commands and data structure. As a result, DDE is even less efficient than the architecture of FIG. 1.
Another example of new developments in operating environment is an architecture used in MS Windows called OLE (Object Linking and Embedding). This architecture allows one application (e.g., a word processor program) to be linked to one or more applications (e.g., a spreadsheet program). In the terminology of OLE, applications can be classified as client applications and server applications. MS Windows uses a "registration database" to maintain a collection of information about OLE applications and file extensions for MS Windows applications. All communication between applications is handled by OLE. Specifically, OLE applications communicate through the use of three dynamic-link libraries: OLECLI.DLL, OLESRV.DLL, and SHELL.DLL. The SHELL.DLL enables applications to communicate with the registration database. The OLECLI.DLL is the OLE client library and the OLESRV.DLL is the server library. The OLE server and client libraries communicate with each other through DDE messages. The typical path of communication for an OLE function includes the call of the function, DDE messages between OLE libraries, and disseminating information to the client and server applications.
In one example, when the OLESRV.DLL library receives notification from the OLECLI.DLL library that a client application needs an object, the OLESRV.DLL library calls appropriate server methods. For example, OLESRV.DLL calls a ServerOpen( ) method when a user activates an object in an OLE client application. The server application then performs the operation of the ServerOpen( ) method. If ServerOpen( ) is performed successfully, the method returns OLE_OK. If ServerOpen( ) is not performed successfully, an OLE_ERROR_OPEN is returned. The client application can then take appropriate actions.
The registration database in OLE contains the linkage or history of the applications. The registration database and the client-server structure of OLE form a boss architecture. Further, even a simple communication between applications requires the involvement of many Windows components (e.g., DDE, dynamic-link libraries, etc.). It is well-known that MS Windows' applications require a lot of memory and processor bandwidth. The boss architecture together with the complicated structure of MS Windows components could be one reason for the slow performance.